\section{Prngd\_Server} 
\label{sec_prngdserver}
Prngd\_Server ist Bestandteil der Aufgabe 2, in der ein Programm Prngd über
verschiedene Schnittstellen wie TCP, UDP, Unix-Domain-Socket und Message-Queue
ansprechbar sein soll. In Abbildung \ref{figure:call_prngd_server} ist zu sehen,
das Prngd\_Server insgesamt bis zu 5 Instanzen von Prngd besitzen kann. Eine
davon ist zur lokalen, direkten Verwendung (ganz links in Abb.
\ref{figure:call_prngd_server}). Die 4 Anderen sind über verschiedene
Server-Objekte ansprechbar. Jede Server-Klasse erbt hierbei von der
Klasse <<MyThreadClass>> und <<Com\_Interface>>. Durch die Verwendung von
Threads können bis zu 4 Schnittstellen gleichzeitig betrieben werden, wobei jede
Schnittstelle nur immer eine Anfrage für Zufallszahlen behandeln kann. Das kommt
daher das jeder Schnittstellen-Server nur eine Instanz von prngd hat und diese
auch nur in einem Thread läuft. Sendet man eine Anfrage an eine Schnittstelle,
welche gerade beschäftigt ist, so erhält man eine Rückmeldung dies bezüglich.
Man muss die Anfrage also zu einem späteren Zeitpunkt erneut senden. Einzige
Ausnahme hierbei bildet der MQ\_Server, da hier durch die Art der Kommunikation
bereits ein FIFO vorgegeben ist. Für alle anderen Server könnte man eine Art
Warteschlange in Form einer Liste implementieren, welche allerdings auch
thread-safe sein muss. Aus Zeitgründen wurde hierauf verzichtet.
Um den Prngd\_Server zu starten kann folgender Kommandozeilenbefehl genutzt
werden:\\

\textbf{./prngd\_server -i tcp -i udp}\\

Dadurch wird der Server mit den Schnittstellen TCP und UDP gestartet. Der Server
kann clientseitig durch senden des Befehls \textbf{/exit} beendet werden.
Allerdings muss dieser Befehl von allen Schnittstellen kommen, im Beispiel also
von TCP und UDP. Kommt der Befehl nur von einer Schnittstelle so laufen die
übrigen weiter. Um über Prngd\_Server lokal Zufallsbits zu erzeugen kann z.B.
der Befehl:\\

\textbf{./prngd\_server -o prngdout -bbs 1024 -s 1234567 -i local}\\

genutzt werden. Hierbei wird der Server durch \textbf{-i local} angewiesen eine
lokale Instanz von <<prngd>> zu öffnen und die anderen Parameter wie in
\ref{sec_prngd} beschrieben zu interpretieren und das Ergebnis in die Datei
"`prngdout"' zu schreiben.

\begin{figure}[H]
\centering
\includegraphics[scale=0.75,keepaspectratio]{./content/images/prngd.png}
\caption{Call-Graph für Prngd\_Server}
\label{figure:call_prngd_server}
\end{figure}

\subsection{Besonderheiten der einzelnen Server} 
\label{subsec:unterschiede}
Insgesamt besitzt Prnd\_Server 5 Instanzen von "`Prngd"', davon laufen 4 auf
Kommunikationsschnittstellen. Zwischen diesen 4 Servern (TCP, UDP, UDS und MQ)
gibt es Unterschiede was die Anzahl der Clients, welche gleichzeitig Anfragen
stellen können, betrifft. 

\begin{description}
\item[Tcp-Server] Der Tcp-Server ist so ausgelegt, dass nur immer ein Client mit
Zufallszahlen bedient werden kann. Andere Clients können zwar den Server
kontaktieren, erhalten aber eine Meldung dass dieser beschäftigt ist.
\item[Udp-Server] Genau wie beim Tcp-Server kann hier auch nur ein Client mit
Zufallszahlen bedient werden, aller weiteren Client erhalten eine Meldung dass
der Server beschäftigt ist.
\item[Uds-Server] Da die Kommunikation eines Unix-Domain-Sockets über eine Datei
läuft, benötigt jede Client-Server-Verbindung eine seperate Datei. In unserer
Beispielkonfiguration gibt kann nur eine Instanz von "`prngd\_client"' eine
Verbindung zum Uds-Server aufbauen, da wir nur eine Socket-Datei anlegen. Der
Start von weiteren Instanzen von "`prngd\_client"' und damit das starten von
paralellen Anfragen, würde zu Fehlerszenarien führen.
\item[MQ-Server] Hier besteht auch ein ähnliches Szenario wie beim Uds-Server.
Für jeden Client müsste der Server eine eigene Messagequeue anlegen. In unserer
Beispielkonfiguration mit "`prngd\_client"' wird lediglich eine Messagequeue für
den Client angelegt. Somit ist auch nur eine Instanz bzw. Verbindung erlaubt.
Für mehrere Verbindungen müsste so etwas wie ein Messagequeue-Manager
implementiert werden. 
\end{description}

\subsection{Com\_Interface und MyThreadClass}
\label{sec:interface}
Jeder Server (TCP, UDP, UDS und MQ) erbt von den Klassen <<Com\_Interface>> und
<<MyThreadClass>>. <<Com\_Interface>> bildet die Basisklasse für alle Server und
beinhaltet z.B. die Instanz von Prngd, Empfangsbuffer, Variablen zur
Signalkonfiguration und Hilfsfunktionen um die empfangenen Befehle von Clienten
auszuwerten. Außerdem werden folgende Funktionen definiert:

\begin{itemize}
  \item thread\_listen(pthread\_t) aka. Listener 
  \item thread\_work() aka. Worker
\end{itemize}

Diese Funktionen werden von jeder Server-Klasse implementiert. Dabei hat der
Worker die Aufgabe die Verbindung in Form von Sockets aufzubauen und empfangene
Befehle auszuführen, worunter auch die Erzeugung von Zufallsbits durch Prngd
fällt. Der Listener hat die Aufgabe auf eintreffende Daten bzw. Befehle zu
warten. Sind Daten eingetroffen, so wird dem Worker per Signalen mitgeteilt was
zu tun ist. Die Erzeugung von Threads wird durch die Klasse <<MyThreadClass>>
vorgenommen. Durch den Aufruf von einer der Funktionen:

\begin{itemize}
  \item StartListenerThread(pthread\_t)
  \item StartWorkerThread()
\end{itemize}

werden die von <<Com\_Interface>> vordefinierten Funktionen "`thread\_listen"'
und "`thread\_work"' in der jeweiligen Server-Klasse in seperaten
Threads aufgerufen. Die Funktion "`StartWorkerThread()" wird hierbei
innerhalb des jeweiligen Server aufgerufen, wodurch intern die Funktion
"`thread\_work()"' in einem seperatem Thread gestartet wird. Anschließend wird
die Funktion "`StartListenerThread(pthread\_t)"' aus der Funktion
"`thread\_work"' heraus aufgerufen wird und als Parameter die Thread-ID des 
Worker-Thread per "`pthread\_self()"' mitgegeben wird. Dadurch kann der Listener 
dem Worker später Signale senden. Zur Verdeutlichung empfiehlt sich ein Blick 
in eine Server-Klasse, z.B. "`Tcp\_Server.cpp"' bzw. in die Doxygen und deren 
Call-Graphen.




\subsection{Prngd}
\label{sec_prngd}
Prngd ist das eigentliche Programm zur Zufallszahlenerzeugung und beinhaltet
einen Generator nach Blum Blum Shub und MARCELS NICHT VORHANDEN GENERATOR.
Anfänglich gab es noch keinen Prngd\_Server, so dass Prngd direkt gestartet
wurde und folgende Parameter zum starten benötigte:

\textbf{./prngd -o prngdout -bbs 1024 -s 1234567}

 \begin{description}
  \item [-o prngdout] Das Ergebnis soll in die Datei prngdout geschrieben
  werden.
  \item [-bbs 1024] Es sollen 1024 Zufallsbits, bevorzugt mit dem BBS erzeugt
  werden.
  \item [-s 1234567] In die Seed des Prngd soll die Zahl 1234567 mit einfließen. 
  \end{description}

Nach der Implementation von Prngd\_Server erhält Prngd diese Parameter durch den
Server. Startet man z.B. den Server mit der lokalen Instanz wie im Kapitel
\ref{sec_prngdserver}. So erhält die interne Instanz von Prngd: "`-o prngdout
-bbs 1024 -s 1234567"' und weiß somit was zu tun ist. Da innerhalb von Prngd mit
sehr großen Zahlen gerechnet werden muss wurde hierfür die
\href{https://gmplib.org/}{GNU MP Bignum Library} verwendet. Nach Befehlseingabe
hat Prngd noch die Aufgabe die eigentliche Seed zu berechnen. Diese setzt sich
aus der Benutzereingabe (im Beispiel: 1234567) und Bits aus "`dev/random"'
zusammen. Möchte man z.B. 1024 Bits generieren, so werden zunächste 1024 Bits
aus "`dev/random"' gelesen. Anschließend werden sie mit der Benutzereingabe per
XOR-Operation verknüpft. Die daraus entstandene Zahl wird an die eigentlichen
Generatoren als Seed weitergegeben.




DOKU ÜBER UMSCHALTFUNKTION HIER EINFÜGEN, KEINE UMSCHALTFUNKTION IM MOMEN DA
ZWEITER GENERATOR FEHLT.

 
\subsection{Blum Blum Shub Generator}
\label{sec_bbs}
Zur Implementierung des BBS Generators wurden die Dokumente \cite{bbs2},
\cite{bbs1}, \cite{bbs3} genutzt. Als Input für den BBS erhalten wir lediglich
die berechnete Seed von Prngd und die Anzahl der zu generierenden Bits. Die
erste Aufgabe von BBS ist die Generierung des Moduls M. Umso mehr Bits wir
erzeugen möchten, umso größer wird M und umso länger dauert die Erzeugung davon.
Denn \(m=p*q\) wobei q und p zwei sichere Primzahlen sein sollen. Für p wurde in
der Implementierung die Größe \(bitCount/2\) gewählt, wobei bitCount die Anzahl
der zu generierenden Zufallsbits ist. Für q wurde die Größe
\(bitCount-(bitCount/2)-1\) gewählt.  Über "`dev/random"' wird zunächst, für p
und q, die entsprechende Anzahl an Bits ausgelesen. Um nun daraus eine Primzahl
zu erzeugen wird die Funktion "`mpz\_nextprime()"' der GNU GMP Bibliothek
genutzt, welche intern mit Miller-Rabin testet. Anschließend wird nun die
Bedingung für eine Blum-Primzahl \(prim \equiv 3 mod 4\) geprüft. Solange die
Bedingung nicht erfüllt ist wird weiter nach einer entsprechenden Primzahl
gesucht.

Anschließend kann der Modul M aus p und q berechnet werden. Bevor wir nun die
Zufallsbits erzeugen, wird noch geprüft ob die Seed nicht zufällig Teiler von
M ist. Wäre dies der Fall, so hätten wir per Zufall M faktorisiert und die
generierten Zufallsbits wären nicht sicher. Ist der GCD von M und der Seed
gleich 1, so wird mit der Erzeugung der Folge \(s_i_+_1 = s^2_i mod\) \(m\)
begonnen. \textbf{Von der, in jedem Schritt, erzeugten Zahl wird lediglich das
letzte Bit genommen und in Array "`byteOutput"' hinzugefügt.}
 
\subsubsection{Zusatz für große Mengen an Zufallsbits}
\label{subsubsec:bbs}
Der BBS-Generator ist zunächst so implementiert, dass sich die Größe von M nach
der Anzahl der zu erzeugenden Bits richtet. Das heißt: Wenn man 1024 Bit
erzeugen möchte, so wird hierfür ein M von 1024 Bit errechnet. Wenn man nun
allerdings mit einem Aufruf 1 Million Bits erzeugen möchte, würde der Generator
versuchen ein M mit 1 Mio. Bits zu erzeugen, was wiederum mit extremer
Rechenzeit verbunden wäre. Um das zu verhinden gibt es die Option
\textbf{-fbbs}. Für das Programm "`Prngd\_Server"' würde der Start also so
aussehen: 

\begin{description}
  \item[./prngd\_server -o fbbsout.bin -fbbs 1000000 -s 1233543 -i local]
\end{description}

Bei der Verwendung von \textbf{-fbbs} werden die zu erzeugenden 1 Mio Bits in
Blöcke von 2048 Bit aufgeteilt. Für jeden Block wird ein neues M von 2048 Bit
berechnet, was recht schnell geht. Als Seed für jeden Block, außer dem Ersten,
wird der vorangegangene Block mit 2048 Bit aus "`/dev/urandom"' per XOR 
verknüpft.

\subsection{Anderer Generator}
MARCEL
\section{Prngd\_Client}
\label{sec:prngdclient}
Das Programm "`prngd\_client"' wurde erstellt um das Programm "`prngd\_server"'
zu testen. Es bietet die Möglichkeit alle 4 Kommunikationsschnittstellen (TCP,
UDP, UDS, MQ) zu testen und generierte Zufallsbits vom Server zu empfangen. Ein
Aufruf von "`prngd\_client"' kann wie folgt aussehen:

\begin{description}
\item[./prngd\_client -bbs 1024 -s 1234567 -i tcp -ip 127.0.0.1]
\end{description}

Somit wird an den Server mit der Ip-Adresse 127.0.0.1 über die Schnittstelle TCP
der Befehel "`-bbs 1014 -s 1234567"' gesendet. Als Antwort hierauf erhält der
Client dann 1024 Bits. Die Antwort wird immer in der Datei "`rndout.bin"'
gespeichert. 
